
This section describes the project structure of an Orchard solution in Visual Studio. The projects and folders are listed in the order they appear in Visual Studio. 

We recommend that you open the Orchard project in Visual Studio and browse through the files as you read this topic.


# Modules
Modules is a Visual Studio solution folder that contains Orchard module projects. All Orchard modules are ASP.NET MVC web application projects.

## Modules\Lucene
The **Lucene** module enables the site to be indexed using Lucene.NET. The index generated by this module is used by the search module to provide an integrated full-text search experience for a website.

## Modules\Orchard.ArchiveLater
The **ArchiveLater** module supports scheduled archiving functionality.

## Modules\Orchard.Blogs
The **Blogs** module is responsible for managing and rendering blogs and blog posts.

## Modules\Orchard.CodeGeneration
The **CodeGeneration** module contains tools to create Orchard components. These tools can be launched from the command line.

## Modules\Orchard.Comments
The **Comments** module is responsible for managing and rendering comments on content items.

## Modules\Orchard.ContentTypes
The **ContentTypes** module enables the creation and alteration of content types through the Orchard dashboard.

## Modules\Orchard.DesignerTools
The **DesignerTools** module contains tools to help web designers develop themes. The tools show all currently displayed shapes and some information to customize them.

## Modules\Orchard.Email
The **Email** module adds functionality for sending email messages.

## Modules\Orchard.Experimental
The **Experimental** module provides the following types of debugging tools:

* Profiling. This includes tools to help profile Orchard applications.
* WebCommandLine. This enables site administrators to execute Orchard.exe commands using a web interface.
* TestingLists. Adds some content definitions to help test lists.

## Modules\Orchard.ImportExport
The **ImportExport** module provides the capability to import and export content-item data.

## Modules\Orchard.Indexing
The **Indexing** module enables the site to be indexed. The index generated by this module can then be used by the search module to provide an integrated full-text search experience for a web site. This module requires an index implementation like the **Lucene** module.

## Modules\Orchard.jQuery
The **jQuery** module contains the jQuery scripts and related script libraries.

## Modules\Orchard.Lists
The **Lists** module provides a preconfigured container-enabled content type.

## Modules\Orchard.Localization
The **Localization** module enables the localization of content items.

## Modules\Orchard.Media
The **Media** module is responsible for managing and rendering media. It currently supports only image files. Files are stored in the current Orchard file system, which can be either the server's physical file system or Azure blob storage.

## Modules\Orchard.MediaPicker
The **MediaPicker** module is the UI for browsing, uploading, and selecting an image for an HTML editor.

## Modules\Orchard.Messaging
The **Messaging** module contains settings that support messaging.

## Modules\Orchard.Migrations
The **Migrations** module provides data migration commands for updating the database schema according to the definition of **Record** classes in code.

## Modules\Orchard.Modules
The **Modules** module enables the site administrator to manage the installed modules and to activate and deactivate features.

## Modules\Orchard.MultiTenancy
The **MultiTenancy** module enables multiple Orchard sites to run in isolation inside a single web application. This improves site density on a single server or hosted account.

## Modules\Orchard.Packaging
The **Packaging** module enables modules to be packaged for distribution using the OPC format.

## Modules\Orchard.Pages
The **Pages** module is responsible for managing and rendering CMS pages. It contains a preconfigured **Page** content type.

## Modules\Orchard.PublishLater
The **PublishLater** module supports draft creation and scheduled publishing.

## Modules\Orchard.Recipes
The **Recipes** module supports Orchard recipes, which enable the automatic configuration of websites.

## Modules\Orchard.Roles
The **Roles** module adds the ability to assign roles to users. It also provides a set of default roles for which other modules can define permissions.

## Modules\Orchard.Scripting
The **Scripting** module enables execution of scripts using a simple scripting language.

## Modules\Orchard.Scripting.Dlr
The **Scripting.DLR** module enables execution of scripts using the DLR.

## Modules\Orchard.Search
The **Search** module enables management of the search index and provides the user interface for Orchard's built-in search.

## Modules\Orchard.Setup
The **Setup** module is responsible for initial setup of the application. This feature is disabled automatically after setup has finished.

## Modules\Orchard.Tags
The **Tags** module is responsible for managing and rendering tags on content items.

## Modules\Orchard.Themes
The **Themes** module makes it possible for Orchard applications to customize the look and feel of an Orchard web site.

## Modules\Orchard.Users
The **Users** module is responsible for managing users.

## Modules\Orchard.Warmup
The **Warmup** module provides a mechanism to generate a static version of pages to use during application initialization.

## Modules\Orchard.Widgets
The **Widgets** module supports Orchard widgets, which are pieces of reusable UI that can be used on pages of a website.

## Modules\TinyMce
The **TinyMCE** module enables rich-text editing.

# Specs
The _Specs_ folder contains the following projects:

* Orchard.Profile. This provides for creating a profiling image for Orchard.
* Orchard.Specs. This contains integration tests written using a [SpecFlow](http://www.specflow.org) style. Feature-specific information is contained in the _*.feature_ files.

# Tests
The _Tests_ folder contains the following projects:

* Orchard.Core.Tests is the test project for the Orchard.Core project.
* Orchard.Framework.Tests is the test project for the Orchard.Framework project.
* Orchard.Tests.Modules is the test project for Orchard modules. It contains subfolders for different modules.
* Orchard.Web.Tests is the test project for the Orchard.Web project.

# Tools
The _Tools_ folder contains the source code for tools that are used to build the Orchard solution. It also contains the Orchard project, which builds the Orchard.exe command-line tool that you can use to run commands defined in an Orchard website in order to automate administrative tasks.

# Orchard.Core
The Core project contains a set of core modules and content types for Orchard, such as feeds, theming, navigation or the common, routable and body content parts.

# Orchard.Framework Project
Orchard.Framework is a class library project containing the Orchard CMS framework.

# Orchard.Web Project
Orchard.Web is an MVC web application project. This is the application that you actually run. It is the startup project of the application. It contains the Orchard CMS core platform binaries and is therefore the Orchard CMS host application.

# Other Notes

* The Orchard.Web project is set as the startup project of the solution (for example, when you use Visual Studio debugging). Orchard.Web dynamically loads all Orchard modules and discovers module extensibility points (MVC routes, admin pages, and so on.)

* The projects in the _Modules_ folder are physically located under the **Ochard.Web\Modules** folder. This allows modules to contain ASP.NET views (_.aspx_, _.ascx_, and other files) and static content without having to copy files between projects to be able to run the project.

* The Orchard.Web project has project references to the modules. This enables automatic copying of the output assemblies into the _bin_ folder of the Orchard.Web project. Orchard.Web has no dependency on types in the _Modules_ assemblies, because the Orchard.Web project is not supposed to have a compile-time knowledge of which modules are loaded at run time. (This is not entirely true at the current stage of Orchard development.)

* The projects in the _Modules_ folder have a project reference to the Orchard project. This allows modules to have access to the base Orchard services.

# About Core Modules

This section discuss some of the design decisions that went into creating core modules. The first issue is this: why are core modules modules? Because during the design phase for Orchard, it was determined that an extensibility point such as modules was needed. Everything else would constitute the core framework. 

For example, the **Common** module introduces **BodyAspect**, a core concept that is common to many types of content types, such as blog posts or pages. This could have been implemented as part of the Orchard framework DLL and could have had modules depend on it. However, then it would not get the benefit of being a module, such as being able to hook up handlers, drivers, views, routes, and so on. This also relates to MVC and areas, where everything that belongs to an area is under the same directory. 

It was determined that the correct approach was to get certain core concepts out of the framework DLL into a separate DLL and have them be modules. This is similar to non-monolithic operating systems where parts of the core functionality are implemented as modules outside the kernel, talking to the kernel using the same interfaces as the more high-level modules.

A second design issue for core modules was this: why are core modules core modules? After it was determined that core concepts would be implemented as modules, it might have made sense to put them into the modules directory along with the rest of the Orchard modules, such as the comments module. 

The problem with that approach was dependencies. In Orchard, modules that are in the modules directory can be disabled, uninstalled, or otherwise updated in a breaking way. Orchard modules should avoid dependencies on other modules as much as possible -- that's part of the dynamism behind the content-type architecture. Pages and blog posts, which belong to the **Pages** and **Blog** modules, don't reference the **Comments** or **Tags** modules, but it's possible to attach comments or tags to pages and blog posts. This decoupled behavior is ensured by the underlying content-type architecture and not by direct reference from another module. 

However, core modules are part of the Orchard framework and it's considered acceptable for modules to depend on them. Core modules will be distributed by the Orchard development team, and for all practical purposes are integral parts of the Orchard framework. Modules can depend on them and directly access their public surface.
